Claims 1-39 cancelled. 

40. (New) A method of wireless connectivity comprising: 

receiving a broadcast beacon at a client; 

the client deriving information from the beacon, the information allowing 
the client to identify all other clients in a multi-hop path from the client to a 
server. 

41. (New) The method of wireless connectivity of claim 40, wherein the information 
identifying the other clients comprises addresses of the other clients. 

42. (New) The method of wireless connectivity of claim 40, wherein beacons are 
originated and broadcast by the server, and are modified and broadcast by clients. 

43. (New) The method of wireless connectivity of claim 40, wherein the client receives a 
plurality of broadcast beacons, modifies at least one of the received beacons, and 
transmits the at least one modified beacon. 

44. (New) The method of wireless connectivity of claim 42, wherein modified beacons 
comprise addresses of clients in the path, and an address of the server. 

45. (New) The method of claim 40, comprising: 

storing every beacon received; 

designating one path identified by one beacon as the optimal path; 
setting a default gateway as identified in the optimal path; and 
rebroadcasting only the beacon representing the optimal path. 

46. (New) The method of claim 42, wherein the beacon broadcast by the server includes 
a hop-count set to an initial value, the method further comprising: 

each client that receives the beacon broadcasting a modified beacon with the hop- 
count incremented by one; 
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such that each client receiving any beacon knows a path to reach the server and 
the number of hops in this path. 

47. (New) The method of claim 40 further comprising: 

each client that receives the broadcast beacon rebroadcasting the beacon with an 
identifier of the client added to the beacon; 

such that any client receiving any beacon has a complete path to the server. 

48. (New) The method of claim 47, wherein the identifier of the client is a client address. 

49. (New) The method of claim 40, wherein the broadcast beacon includes a sequence 
number representing a current routing cycle. 

50. (New) The method of claim 49, further comprising upon a client receiving a beacon, 
determining if a beacon was previously received for this routing cycle; and 

if no beacon was previously received for the routing cycle, storing a routing path 
to the server from the beacon. 

51. (New) The method of claim 49, further comprising, if the beacon was previously 
received for the routing cycle: 

determining if this beacon has a higher sequence number than a prior beacon for 
this routing cycle, and if so, 

storing the current beacon in memory. 

52. (New) The method of claim 49, further comprising, 

upon a client receiving a beacon, determining if a currently received beacon 
represents an optimal path for this routing cycle; and 

if the current beacon represents the optimal path, identifying a default gateway in 
the current beacon, and storing the default gateway. 

53. (New) The method of claim 44, further comprising: 
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determining if there is a previous default gateway identified; and 
deleting the previous default gateway from memory. 

54. (New) The method of claim 40, further comprising, for each client: 

collecting all beacons; and 

selecting a single beacon to broadcast. 

55. (New) The method of claim 54, wherein selecting a beacon comprises: 

identifying a number of hops between the server and the client for each beacon; 

and 

selecting the beacon with the lowest number of hops. 

56. (New) The method of claim 54, wherein selecting a beacon comprises: 

identifying a traffic monitoring code (TMC) for each of the 
beacons; and 

selecting the beacon with the lowest TMC. 

57. (New) The method of claim 54, wherein selecting a beacon comprises: 

identifying a beacon with a highest quality; and 
selecting the beacon with the highest quality. 

58. (New) The method of claim 57, wherein the highest quality is a best signal-to-noise 
ratio. 

59. (New) The method of claim 57, wherein the highest quality is based on most back end 
bandwidth capacity at the server. 

60. (New) The method of claim 57, wherein the highest quality is based on a lowest level 
of traffic being handled by the server. 

61. (New) The method of claim 57, wherein the highest quality is based on a reliability of 
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the beacon. 



62. (New) The method of claim 61, wherein the reliability is determined by a number of 
times the beacon is received compared to a number of times the beacon was broadcast 
over a period of time. 

63. (New) The method of claim 40, further comprising: 

sending a reverse beacon to the server; and 

constructing a client tree in the server, wherein the server has a path to all clients. 

64. (New) A server for wireless communications comprising: 

a beacon logic to generate a beacon and broadcast the beacon; and 

a wireless transceiver to receive a plurality of reverse beacons, the reverse 

beacons including information identifying all other clients in a multi-hop path to each of 

the clients; and 

a client tree storing information identifying other clients in the path to each of the 
clients, such that the server can send data to any client, either directly or through other 
clients on the network. 

65. (New) The server of claim 64, further comprising a monitoring logic to monitor a 
network, the monitoring logic using the client tree to generate a map of the network 
of clients. 

66. (New) A method of generating a routing path for a system including a server and a 
plurality of clients, the method comprising each client: 

receiving a beacon from the server; 

the client deriving information from the beacon, the information allowing the 
client to identify all other clients in a multi-hop path from the client to a server; 
rebroadcasting one beacon received from an upstream node; and 
broadcasting a reverse beacon upstream, the reverse beacon being addressed to 
the known upstream node, the reverse beacon used by the server and each client to set up 
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a routing table. 

67. (New) The method of claim 66, wherein a routing table in a particular client includes 
a default gateway and a path to each client downstream from the particular client. 

68. (New) The method of claim 66, further comprising the server broadcasting a dummy 
reverse beacon to initiate the reverse beacon cycle. 

69. (New) The method of claim 66, further comprising each client aggregating the 
reverse beacons received from downstream clients, and sending a single reverse 
beacon including the aggregated information. 

70. (New) The method of claim 66, wherein 

receiving a reverse beacon broadcast by a client's default gateway triggers the 
client to start a timer to send the reverse beacon. 

71. (New) The method of claim 66, 

further comprising, if a client receives multiple beacons: 
evaluating a link quality of each of the beacons received; and 
selecting the default gateway based on the beacon with the best link quality and 
rebroadcasting that beacon. 

72. (New) The method of claim 71, wherein the link quality comprises reliability of the 
beacon. 

73. (New) The method of claim 71, wherein the link quality includes information about 
the back end bandwidth capacity of the server. 

74. (New) The method of claim 71, wherein the link quality includes information about 
the traffic being handled by the server. 
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75. (New) The method of claim 66, wherein a connection between the server and the 
client is a wireless connection. 

76. (New) The method of claim 66, wherein a connection between the server and the 
client is chosen from among the following types of connections: a wireless 
connection, a wired connection, and a switched connection. 

77. (New) The method of claim 66, 

further comprising the client: 

receiving a plurality of beacons from a plurality of servers; and 
selecting one of the plurality of beacons, and setting the server associated with the 
selected beacon as its preferred server; 

thereby self-selecting to belong in a cluster associated with the preferred server. 

78. (New) The method of claim 77, further comprising the client: 

moving outside the cluster; 

upon receiving a beacon from a new cluster, the client setting the server 
associated with the new beacon and the new cluster as its preferred server. 

79. (New) The method of claim 78, further comprising: 

expiring a routing table including a previous preferred server and previous default 
gateway. 
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REMARKS 



The Examiner initially rejected the parent patent application of this continuing 
patent application based upon cited prior art. More specifically, the Examiner rejected 
some of the claims of the parent US patent application (Serial Number 09/751,262) as 
being anticipated by Mahany et al. (5,740,366). 

For convenience, applicants have reviewed Mahany et al, and provided reasons 
why the claims of this patent application are patentable over Mahany. 

New claim 40 includes the features of: 

receiving a broadcast beacon at a client; 

the client deriving information from the beacon, the information allowing 
the client to identify all other clients in a multi-hop path from the client to a 
server . 

(Emphasis added) 

Mahany teaches broadcasting of Hello packets that include the following 
information: 

1) The address of the sender, 2) the hopping distance that the sender is 
from the root, 3) a source address, 4) a count of nodes in the subtree 
which flow through the bridge, and 5) a list of system parameters. 
Essentially, the Hello packets of Mahany provide information indicating the 
existence of a path to a server of a multi-hop path, whereas the claimed invention 
includes; the client deriving information from the beacon, the information allowing the 
client to identify all other clients in a multi-hop path from the client to a server . 

The Hello packets of Mahany do not include enough information for a client to 
identify all other clients in a multi-hop path from the client to a server. The Hello packets 
of Mahany only include the address of sender of the Hello packet, the source address and 
the count of nodes in the subtree. 
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The Hello packets do not includes enough information for a client to 
advantageously select an optimal multi-hop path from the client to a server. 

Each node in Mahany "stores and modifies information which specifies how local 
communication traffic should flow" (column3, lines 40-45). 

Independent claim 64 includes the following features: 

a beacon logic to generate a beacon and broadcast the beacon; and 

a wireless transceiver to receive a plurality of reverse beacons, the reverse 

beacons including information identifying all other clients in a multi-hop path to each of 

the clients ; and 

a client tree storing information identifying other clients in the path to each of the 
clients, such that the server can send data to any client, either directly or through other 
clients on the network. 

As previously stated, the Hello packets of Mahany provide information indicating 
the existence of a path from a client to a server of a multi-hop path, whereas the beacons 
of the claimed invention include information identifying all other clients in a multi-hop 
path to each of the clients. The Hello packets of Mahany do not include enough 
information for a server to identify all other clients in a multi-hop path from the server to 
a client. Each node within Manhany specifies how local communication traffic should 
flow. 

Independent claim 66 includes features of claim 40 that make the claim patentably 
distinct over Mahany. 
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